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METHODS AND APPARATUS FOR ENTERPRISE APPLICATION INTEGRATION 
Background of the Invention 

This application claims the benefit of priority of U.S. provisional patent application Serial 
No. 60/291,185, filed on May 15, 2001, entitled "Methods and Apparatus for Enterprise 
5 Application Integration," the teachings of which are incorporated herein by reference. 

The invention pertains to digital data processing and, more particularly, to methods and 
apparatus for enterprise application integration. It has application in the dynamic consolidation 
of disparate databases, e.g., of marketing, e-commerce or other transactional data, over a 
1 0 network, such as the Internet. 




□ It is not uncommon for a single company to have several database systems - separate 

' » systems not interfaced - to track internal and external planning and transaction data. Such 
systems might of been developed at different times throughout the history of the company and 

~"'zA 

15 are therefore of differing generations of computer technology. For example, a marketing 
? ~ database system tracking customers may be ten years old, while an enterprise resource planning 
(ERP) system tracking inventory might be two or three years old. Integration between these 

l3 

systems is difficult at best, consuming specialized programming skill and constant maintenance 
expenses. 

il 

A major impediment to enterprise application integration (EAI) is the consolidation of 
these disparate legacy databases with one another and with newer e-cornmerce databases. For 
instance, inventory on-hand data gleaned from a legacy ERP system may be difficult to combine 
with customer order data gleaned from web servers that support e-commerce (and other web- 
25 based) transactions. This is not to mention difficulties, for example, in consolidating resource 
scheduling data from the ERP system with the forecasting data from the marketing database 
system. 



30 



An object of this invention is to provide improved methods and apparatus for digital data 
processing and, more particularly, for enterprise application integration. 
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A further object of the invention is to provide such methods and apparatus as can be 
readily and inexpensively integrated with legacy, current and future database management 
systems. 

5 

A still further object of the invention is to provide such methods and apparatus as can be 
implemented incrementally or otherwise without interruption of enterprise operation. 

Yet a still further object of the invention is to provide such methods and apparatus as to 
10 facilitate ready access to up-to-date enterprise data, regardless of its underlying source. 

□ 

*0 Yet still a further object of the invention is to provide such methods and apparatus as 

=0 

U permit flexible presentation of enterprise data in an easily understood manner. 



Summary of the Invention 
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The aforementioned are among the objects attained by the invention, one aspect of which 
provides a method for enterprise application integration that uses software ("connectors") that 
5 can be instantiated via downloading (e.g., using Java® or other such technologies) to provide 
interfaces to respective disparate database systems. The databases systems may comprise any 
variety of now or heretofore known systems, e.g. SAP, Oracle, and so forth. 

The connectors can, for example, translate between a native language (or API) of the 
1 0 respective database systems and an internal language/protocol of the enterprise application 
integration system. To this end, the connectors can utilize a scripting language to access the 
respective database systems. 



I* 



Another aspect of the invention provides methods as described above that store data 



IS accessed from the database systems in a central data store, referred to below as a "holographic" 
data store. That data can be stored, for example, as resource definition framework (RDF) 

s 

P triplets. 

!U 

13 The connectors, according to further aspects of the invention, can query the respective 

io database systems based on requests received from the holographic data store and/or from a 

framework server, a user or otherwise. In related aspects, the data store is periodically updated 

via application of queries to the database systems. 

Further aspects of the invention provide methods as described above in which a graph 
25 generator generates directed graphs from the RDF triplets in the holographic store. The graphs 
can be "walked" in order to discern answers to queries for information reflected by triplets 
originating from data in one or more of the databases. 
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Another aspect of the invention provides methods as described above in which a 
framework server accepts queries, e.g., from a user, and formats them for application to the 
holographic data store. 

5 Further aspects of the invention provide enterprise application integration systems that 

operate in accord with the foregoing. 

These and other aspects of the invention are evident in the drawings and in the 
description that follows. 

10 



I* 



o 



-4- 



EL 835 825 393 US 




BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing features of this invention, as well as the invention itself, may be more fully 
understood from the following detailed description of the drawings in which: 

5 

Figure 1 depicts an improved enterprise application integration system according 
invention; 

Figure 2 depicts operation of a software interface "connector" according to the invention; 

10 

!3 Figure 3 depicts data flow within a connector according to the invention; and 

=0 

*J Figure 4 depicts a directed graph representing data triplets of the type maintained in a 

iij 

JS. data store according to the invention. 
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DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENT 



Figure 1 depicts a enterprise application integration system according to the invention. 
The illustrated system 100 includes connectors 108 that provide software interfaces to legacy, e- 
5 commerce and other databases 140 (hereinafter, collectively, "legacy databases"). A 

"holographic" database 1 14 (hereinafter, "data store" or "holographic data store"), which is 
coupled to the legacy databases 140 via the connectors 108, stores data from those databases 
140. A framework server 1 16 accesses the data store 114, presenting selected data to (and 
permitting queries from) a user browser 118. The server 116 can also permit updates to data in 
10 the data store 114 and, thereby, in the legacy databases 140. 



^ Legacy databases 140 represent existing (and future) databases and other sources of 

*0 information in a company, organization or other entity (hereinafter "enterprise"). In the 

' y illustration, these include a retail e-commerce database (e.g., as indicated by the cloud and server 

1§ icons adjacent database 140c) maintained with a Sybase® database management system, an 

s p inventory database maintained with an Oracle® database management system and an ERP 

p database maintained with an SAP® database management system. Of course, these are merely 
examples of the variety of databases or other sources of information with which methods and 

! *J 

H *4 apparatus as described herein can be used. Common features of illustrated databases 140 are that 

20 they maintain information of interest to an enterprise and that they can be accessed via respective 

i 

software applications program interfaces (API) or other mechanisms known in the art. 



Connectors 108 serve as an interface to legacy database systems 140. Each connector 
applies requests to, and receives information from, a respective legacy database, using that 
25 database's API or other interface mechanism. Thus, for example, connector 108a applies 

requests to legacy database 140a using the corresponding SAP API; connector 108b, to legacy 
database 140b using Oracle API; and connector 108c, to legacy database 140c using the 
corresponding Sybase API. 
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In the illustrated embodiment, these requests are for purposes of accessing data stored in 
the respective databases 140. The requests typically originate in the holographic data store 1 14 
or the framework server 1 16, wherefrom they are routed to the connectors via the store 114. 
Alternatively or in addition, the requests can originate, in the first instance, from the connectors 
5 108 themselves, e.g., by way of pre-programming or otherwise. Regardless of their origin, the 
requests can be stored in the connectors 108 for application and/or reapplication to the respective 
legacy databases 108. 

Data and other information (collectively, "messages") generated by the databases 140 in 
1 0 response to the requests are routed by connectors to the holographic data store 1 14. Those 

messages can be cached by the connectors 108, though, they are preferably immediately routed 
i~ to the store 114. 



h e 

4 



IU 

id 



25 



The software connectors 108 may reside on any digital data processing system(s) that is 
(are) in communications coupling - e.g., via a dial-up connection, bus, cable, network and/or 
Internet (as indicated by cloud icons), or otherwise — with the respective legacy databases 140 
and with the holographic data store 114. Typically, the connectors reside on computers within 
the firewall (or other security barrier) of the enterprise, though, they may reside elsewhere (e.g., 
local to the holographic store 1 14 and/or the framework server 116). 

In a preferred embodiment, the connectors are implemented as Java® servlets, or the like, 
though they can be implemented in any programming language. Indeed, the connectors 
fabricated as special purpose hardware devices, though, such hardware lacks one of the 
immediate advantages of Java (or other software) implementations - to wit, the ability to 
download and/or remotely implement, upgrade and maintain it. 



30 



In embodiments, such as that illustrated here, wherein the connectors 108 are 
implemented as Java® servlets, or the like, those connectors preferably execute with a suitable 
environment, e.g., utilizing Java virtual machines running scripted Extensible Markup Language 
("XML") operating according Extensible Stylesheet Language Transformation ("XSLT") scripts. 
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A suitable environment for accomplishing this is Tomcat running under Cocoon 2, both available 
as from Apache Software Foundation or in the alternative, WebSphere available from IBM 
Corporation. As such, the use of XSLT scripts allow the connector to communicate with a 
variety of database systems by merely downloading the XSLT using any computer readable 
5 medium, e.g. disk, electronic download, or CD-ROM. 

Referring to Figure 2, the connectors translate between the API (or other interface 
mechanisms) of the legacy databases 140 and a language/protocol common to the connectors 
108, the holographic data store 1 14 and the framework server 116. In the illustrated 

10 embodiment, that common language/protocol is referred to Intelligent Connector Query 
Language (ICQL), though, it will be appreciated that other embodiments may use other 

P languages/protocols and, indeed, may not utilize a common language/protocol at all. Thus, for 
example, requests generated by holographic data store 1 14 and routed to connector 108a in ICQL 

!« (or other language/protocol) are converted (or translated or transformed) by that connector into 

■J 

15 an appropriate API call to legacy database 140a. Likewise, messages generated by that database 

^fj 140a in response to such a request are converted by the connector 108a back into ICQL (or other 

5 language/protocol). 

: c r 

A more complete understanding of the operation of the connectors 108 may be attained 
by reference to Figure 3, which shows data flow within a connector 300 according to one 
embodiment of the invention. 

Illustrated is a connector 300 utilizing Hypertext Transfer Protocol ("HTTP") as a vehicle 
to transfer messages (e.g., requests and responses thereto) with holographic data store 114, such 

25 as the one illustrated in Figure 1 . Each message 302 (e.g., request) originating from the data 

store 1 15 is processed by request, match and action modules 304 - 308, as shown. The message 
is sent to the connected legacy database, e.g., 140a, using the appropriate API or other interface 
mechanism. It will be apparent to those of ordinary skill in the art that the actual transformation 
sequence is dependent on the type of legacy database system being accessed and the method of 

30 communication between the holographic data store and the connector framework. 
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Messages received by the connector 300 from the legacy database are likewise processed 
for return to the holographic data store 114. In the illustrated example, a message 3 1 8 is 
received and routed to a generator module 314 which performs a transformation according to a 
5 XSP script, and then routes the message to a transformer module 312. The transformer module 
302 transforms the data field contained within the message into RDF triplet form suitable for the 
holographic data store 1 14 to catalog, and assigns a unique Universal Identification Number 
("UID") for later conversion into a Universal Resource Locator ("URL") by the data store 1 14. 
Finally, the message is routed to a serializer module 310 and transformed for HTTP transfer to 
1 0 the holographic data store 320. 

□ Through use a connector framework comprised of selectable modules, the connectors 

^ may be electronically downloaded or otherwise remotely updated as required. Moreover, 
|* multiple engines/modules can be inserted in the internal data pipeline of connector 300. Each 
f§ such module transforms the data and passes it along the stream. 

in 

i — ' 

13 Referring back to Figure 1, the holographic data store 1 14 stores data from the legacy 

databases 140 and from the framework server 1 16 as RDF triplets. The data store 1 14 can be 
N embodied on any digital data processing system or systems that are in communications coupling 

n 

38 (e.g., as defined above) with the connectors 108 and the framework server 1 16 capable of 
supporting Java ® running XML/XSLT as defined above. Typically, the data store 1 14 is 
embodied in a workstation or other high-end computing device with high capacity storage 
devices or arrays, though, this may not be required for any given implementation. 

25 Though the holographic data store 114 may be contained on an optical storage device, 

this is not the sense in which the term "holographic" is used. Rather, it refers to its storage of 
data from multiple sources (e.g., the legacy databases 140) in a form which permits that data to 
be queried and coalesced from a variety of perspectives, depending on the needs of the user and 
the capabilities of the framework server 116. To this end, a preferred data store 1 14 stores the 



-9- 



EL 835 825 393 US 

data from the legacy databases 140 in object-predicate-subject form, e.g., RDF triplets, though 
those of ordinary skill in the art will appreciate that other forms may be used as well, or instead. 

Referring to Figure 4, the data store can store - by way of non-limiting example - RDF 
5 triplets representing data from marketing and/or e-commerce "legacy" databases. The figure 
particularly illustrates triplets representing hotel reservation transactions. Each triplet comprises 
a predicate 402, subject 406 and object 408 such that the object 408 is "linked" to its subject(s) 
406 via predicate(s) 402. 

10 In the illustrated example, each predicate 402 is assigned a Uniform Resource Indicator 

("URI") 410 such that related data is located via URTs in a hierarchical ordering, represented for 
igst example by the directed arrow 402. If the triplet is high-level 408 its URI 404 points to a lower 

\Q set of triplets 412, each of which has a URI 414 that may point to data or to further triplets 416. 

U 

\^ x Each subject 406 contains transactional information pertaining to an enterprise resource 

S P item, e.g. credit card type, type of product bought or date. For example, as illustrated in Figure 

□ 4, a typical subject 420 shows a value of "data of departure" related to a hotel booking 

||j transaction. It can be appreciated from one in the art that many different types of data may be 

s. : 

^ contained within the subject, e.g. literal values, referenced values or additional URTs. 

An object 408 contains information pertaining to the "who" of the transaction, such as the 
person or enterprise initiating the transaction. The object, similar to the subject, may be a literal, 
e.g. "Smith", or a unique identifier such as a locator address 422 such that each related predicate 
and subject can be referenced through the object. 

25 

It can be appreciated that any given transaction (or other event that gives rise to triplets of 
the type stored in the data store 1 14) may be reflected in multiple legacy database systems 140. 
When those systems are queried by the connectors, this may result in multiple triplets causing 
redundant or related information to be stored within the holographic store 1 14. The illustrated 
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data store 1 14 includes a relationalizer that periodically passes through the retained triplets to 
combine these related triplets into "bags/' at the same time removing any redundancies as 
determined by a calculated confidence level or other similar technique. This can be performed 
by comparing sequential levels of objects and merging triplets and bags of similar objects. For 
5 example, two people at the same address and same last name may be merged into a "family" bag, 
and so on. In this way, data storage is both minimized and related such that queries can be 
executed using the minimal execution time. The data store 1 14 can also remove redundant 
information from the legacy databases 140 in a similar manner dependent on the capabilities of 
the specific database. 

10 

The data store 1 14 includes a graph generator (not shown) that uses the stored triplets to 
13 generate directed graphs in response to queries (e.g., in ICQL form) from the framework server 

, Ft. 

116. These may be queries for information reflected by triplets originating from data in one or 
!» more of the legacy databases 140 (one example might be a request for the residence cities of 

l H 

hotel guests who booked reservations on account over Independence Day weekend, as reflected 
*£] by data from an e-Commerce database and an Accounts Receivable database). Such generation 
i of directed graphs from triplets can be accomplished in any conventional manner known the art 
^rj (e.g., as appropriate to RDF triples or other manner in which the information is stored). Directed 
=y graphs generated by the data store are passed back to the server 1 16 for presentation to the user. 

28 

In the event that the data store 1 14 does not include sufficient information (e.g., triplets) 
necessary to respond to a query from the framework server 1 16, it can pass the query directly to 
the connectors 108 for application to the legacy databases 140. Alternatively or in addition, the 
data store 1 14 can construct further queries necessary to "fill out" the triplet store with legacy 
25 database information necessary to respond to the query. 

In a preferred embodiment, illustrated data store 1 14 polls the legacy database systems 
140 (via connectors 108) to obtain current information at pre-determined intervals, times or 
otherwise. This can be accomplished using the queries stored within the data store 1 14 or the 
30 connectors 108 themselves. 
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Referring back to Figure 1, the framework server 116 generates requests to the data store 
114 (and/or indirectly to the legacy databases via connectors 108, as discussed above) and 
presents information therefrom to the user via browser 118. The requests can be based on ICQL 
5 requests entered directly by the user though, preferably, they are generated by the server 1 16 
based on user selections/responses to questions, dialog boxes or other user-input controls. In a 
preferred embodiment, the framework server includes one or more user interface modules, plug- 
ins, or the like, each for generating queries of a particular nature. One such module, for example, 
generates queries pertaining to marketing information, another such module generates queries 
10 pertaining to financial information, and so forth. 

1 3 In addition to generating queries, the framework server (and/or the aforementioned 

& a modules) "walks" directed graphs generated by the data store 1 14 to present to the user (via 
H browser 118) any specific items of requested information. Such walking of the directed graphs 

IS can be accomplished via any conventional technique known in the art. Presentation of questions, 

ifi 

p dialog boxes or other user-input controls to the user and, likewise, presentation of responses 

l _ thereto based on the directed graph can be accomplished via conventional server/browser or 

si 

*tj other user interface technology. 

lU 

f3 

In some embodiments, the framework server 1 16 permits a user to update data stored in 
the data store 1 14 and, thereby, that stored in the legacy databases 140. To this end, changes 
made to data displayed by the browser 1 18 are transmitted by server 1 16 to data store 1 14. 
There, any triplets implicated by the change are updated and forwarded to the respective legacy 
databases 140, which utilize the corresponding API (or other interface mechanisms) to update 
25 their respective stores. 

In some embodiments, the server 1 1 6 can present to the user not only data from the data 
store 1 1 4, but also data gleaned by the server directly from other sources. Thus, for example, the 
server 1 16 can directly query an enterprise website for statistics regarding web page usage, or 
30 otherwise. 
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A further understanding of the operation of the framework server 1 16 and of the 
illustrated embodiment may be attained by reference to the appendix filed herewith. 




Described herein are methods and apparatus meeting the above-mentioned objects. It 
5 will be appreciated that the illustrated embodiment is merely an example of the invention and 
that other embodiments, incorporating changes to those described herein, fall within the scope of 
the invention. What we claim is: 



